Skip to content

remove requirement to track demand beyond Long.MAX_VALUE #203

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 23, 2015

Conversation

rkuhn
Copy link
Member

@rkuhn rkuhn commented Jan 16, 2015

fixes #196

Also terminate spec rule sentences with a full stop where missing.

| <a name="3.14">14</a> | While the `Subscription` is not cancelled, invoking `Subscription.cancel` MAY cause the `Publisher`, if stateful, to transition into the `shut-down` state if no other `Subscription` exists at this point [see [1.13](#1.13)]. |
| <a name="3.15">15</a> | `Subscription.cancel` MUST NOT throw an `Exception` and MUST signal `onError` to its `Subscriber`. |
| <a name="3.16">16</a> | `Subscription.request` MUST NOT throw an `Exception` and MUST signal `onError` to its `Subscriber`. |
| <a name="3.17">17</a> | A `Subscription` MUST support an unbounded number of calls to request and MUST support a demand (sum requested - sum delivered) up to 2^63-1 (`java.lang.Long.MAX_VALUE`). A demand equal or greater than 2^63-1 (`java.lang.Long.MAX_VALUE`) MAY be considered by the `Publisher` as effectively unbounded[[1](#footnote-3-1)]. |
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only rule line with more than a simple “full stop” change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't the TCK need to get updated as well?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this PR should remove required_spec317_mustSignalOnErrorWhenPendingAboveLongMaxValue now, that it may just ignore additional requests after MAX_VALUE is reached.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping @rkuhn RE TCK update

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay, the TCK update is pushed now as a separate commit.

@drewhk
Copy link
Contributor

drewhk commented Jan 16, 2015

LGTM

@viktorklang
Copy link
Contributor

I suspect @benjchristensen will like this (IIRC he proposed this change a while back?)

@viktorklang
Copy link
Contributor

@reactive-streams/contributors Please comment/vote/give thumbs up before the 23rd of January.
@rkuhn Please update TCK accordingly on this PR.

@smaldini
Copy link
Contributor

+1

On Tue, Jan 20, 2015 at 2:06 PM, Viktor Klang (√) [email protected]
wrote:

@reactive-streams/contributors
https://github.com/orgs/reactive-streams/teams/contributors Please
comment/vote/give thumbs up before the 23rd of January.
@rkuhn https://github.com/rkuhn Please update TCK accordingly on this
PR.


Reply to this email directly or view it on GitHub
#203 (comment)
.

Stéphane

@benjchristensen
Copy link
Contributor

👍

@smaldini
Copy link
Contributor

Does that mean we ignore all together the request or we switch to the Long.MAX behavior in that case ?

@viktorklang
Copy link
Contributor

@smaldini Typically I'd say implementations will add the requested number to current demand and cap currentDemand at Long.MAX_VALUE

@smaldini
Copy link
Contributor

So @viktorklang effectively turning a Subscription into unbounded mode amIright?

@drewhk
Copy link
Contributor

drewhk commented Jan 22, 2015

I guess that can be left unspecified.

fixes #196

Also terminate spec rule sentences with a full stop where missing.
@rkuhn
Copy link
Member Author

rkuhn commented Jan 23, 2015

All updated including a TCK test that fails if onError is signaled after demand-overflowing request calls. There are several +1 already on this PR, when should we merge?

@ktoso
Copy link
Contributor

ktoso commented Jan 23, 2015

example publisher and tck changes - LGTM 👍

@viktorklang
Copy link
Contributor

Yep, comments were due before the 23rd, merging!

viktorklang added a commit that referenced this pull request Jan 23, 2015
remove requirement to track demand beyond Long.MAX_VALUE
@viktorklang viktorklang merged commit e521dbc into master Jan 23, 2015
@viktorklang viktorklang deleted the wip-196-RK branch January 23, 2015 22:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Request saturation (rule 3.17)
6 participants